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Description 

Field of the Invention 

[0001] This invention relates to a method for network 
dejittering and client/server timing synchronization in 
network (such as IP network) applications for real-time 
audio/visual services. This technique may be used for 
the A/V stream (i.e. MPEG stream) decoder to smooth 
the network jitter and to slave its timing to the encoder 
by a software approach. With this method, a client can 
playback the A/V streams over an IP network with no 
requirement of a PLL (Phase Lock Loop) circuit in the 
decoder. 

Background of the Invention 

[0002] With the continuing growing of Internet and IP- 
related technologies, there is a growing demand for ac- 
cess to multimedia application across a IP-based net- 
work. Unlike the traditional point-to-point network appli- 
cations, emerging multimedia applications such as live 
or storage distance learning, TV broadcast directly to 
desktop via IP network, and desktop conferencing de- 
pend on the ability of multicasting for real-time services. 
The rising need for these kind of applications presents 
the challenge for network and end-systems. It is well 
known that the Internet has been used primarily for the 
reliable transmission of conventional data with minimal 
or no constraints of delay. Its protocols such as TCP/IP 
were well designed for this type of traffic using "Pull" 
mode. However, multimedia data such as audio and vid- 
eo are delay sensitive. Such traffic possesses different 
characteristics and may require different protocols in or- 
der to effectively provide real-time services. For digital 
A/V broadcast services, it requires appropriate "Push" 
mode operation with large uni-directional channel, with 
a small (or no) return channel required. 
[0003] As one of the main requirements for an I P net- 
worked digital audio/visual system, people expect that 
the system will allow the ability to receive or playback 
audio/visual information over the IP network in a real- 
time fashion. However, due to the nature of the IP, low 
layer network access and platform dependant system 
clock, three main problem issues must be faced. One 
problem is the quality of service (QoS). A second prob- 
lem is that there is a significant amount of delay variation 
(jitter) presented in an end-to-end system over IP net- 
work. When an MPEG system stream is transmitted 
over a jitter-inducing network, the real byte data delivery 
schedule may differ significantly from the intended de- 
livery schedule. In such a situation, it is not possible to 
decode the system stream on a standard target decod- 
er, because jitter may cause buffer overflows or under- 
flows and also make it difficult to recover the time base. 
The third problem is the unmatched clocks (time drift) 
between server (encoder) and client (decoder). The 
time drift means that the free-running clock in the client 



will introduce some amount of timing difference over a 
given period of time when compared to the server's en- 
coding clock since there is no guarantee of clock accu- 
racy. The first problem relates to the issue of how to 
5 guarantee the bandwidth and delay for the data delivery 
over an IP network and is currently addressed by the 
IETF. Available technologies addressing this problem 
are: Resource Reservation Protocol (RSVP), Differen- 
tial Service, Multi- Protocol Label Switching (MPLS), etc. 
10 The embodiments of the present invention are intended 
for addressing the other two problems. These two prob- 
lems cause the difficulty for clients to decode data ac- 
curately and playback in a real-time mode using con- 
ventional technology. 
15 [0004] The problem of using the existed technology 
in such a system can be illustrated by the example de- 
scribed below. For example, within an MPEG-2 system 
data stream there are clock time reference timestamps. 
These references are samples of the system time clock 
20 and have a resolution of one part in 27,000,000 per sec- 
ond. They occur at intervals up to 1 00 ms in Transport 
Streams (TS) or up to 700 ms in Program Streams (PS). 
In the PS, the clock field is called the System Clock Ref- 
erence (SCR). In the TS, it is called the Program Clock 
25 Reference (PCR). The SCR (or PCR) field indicates the 
correct value of the STC (System Time Clock - a com- 
mon time base) when the SCR (or PCR) is received at 
the decoder. In concept, this STC value is the same val- 
ue that the encoder's STC had when the SCR (or PCR) 
30 was stored or transmitted. If the decoder's clock fre- 
quency matches exactly that of the encoder, then the 
decoding and presentation of audio/video will automat- 
ically have the same rate as those at the encoder. In 
practice, a decoder's system clock frequency will not 
35 precisely match the encoder's system clock frequency. 
[0005] The decoder's STC can be made to slave its 
timing to the encoder using the received SCRs (or 
PCRs). The prototypical method of achieving such syn- 
chronization is via a Phase-Locked Loop (PLL). The de- 
40 tails on the operation of PLL in this context may be found 
in ISO/IEC International Standard 13818-1, "Generic 
Coding of Moving Pictures and Associated Audio Infor- 
mation: Systems", July 1995. There is a bounded max- 
imum interval between successive SCRs (or PCRs) in 
45 order to allow the operation of PLL to be stable. In a jitter 
introducing network, packet delay variation is consid- 
ered to be quite significant for the MPEG Standard Tar- 
get Decoder (STD). Such timing jitter at the input to a 
decoder is reflected in the combination of the values of 
so SCRs (or PCRs) and the times when they are received. 
A significant SCRs (PCRs) jitter may cause the difficulty 
for the PLL to reach a defined locked state. The effect 
of such clock frequency mismatch between client and 
server is the gradual and unavoidable increase or de- 
55 crease of the fullness of the decoder's buffers, such that 
overflow or underflow would occur eventually with any 
finite size of decoder buffers, therefore, effecting the 
system performance of the overaii operation. 
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[0006] US5633871 discloses reducing the jitter of au- 
dio/video packets. When the value of the local clock cor- 
responds to the time stamp, the packet is sent to the 
decoder. 

[0007] It is an object of the present invention, to pro- 
vide a technique for dejittering and clock recovery for 
use in the client application of a networked real-time au- 
dio/visual service system, it is desirable to be able to 
implement embodiments of the invention to synchronize 
the clients to a server in a jitter introducing network en- 
vironment without employing additional devices or a 
special decoder. 

Summary of the Invention 

[0008] In accordance with the present invention, there 
is provided a method for clock variation compensation 
in an audio/visual system in which encoded A/V data in 
a plurality of data packets are delivered to at least one 
client over a network from a server at a substantially 
constant bit rate, said plurality of data packets including 
data packets containing time stamp data, the method 
comprising the steps of: 

receiving and buffering the data packets in a first 
buffer at a client; 

passing selected data packets from the first buffer 
to a second buffer at scheduled times based on a 
comparison between a local clock of the client and 
timestamp data corresponding to the selected data 
packets; and 

passing the data from the second buffer to a data 
decoder of the client. 

[0009] Preferably the method includes monitoring the 
fullness of the second buffer to derive a drift rate, and 
adjusting the client local clock based on the derived drift 
rate. 

[0010] The present invention further provides an au- 
dio/visual system coupled to receive data packets over 
a network for A/V decoding by an A/V decoder, the sys- 
tem including a clock variation compensation system 
comprising: 

a dejitter buffer for receiving and storing packets of 
data from the network; 

a synchronization buffer for feeding data for decod- 
ing to the A/V decoder; 
a decoder system clock; and 
a buffer data flow controller for controlling the pass- 
ing of selected data packets from the dejitter buffer 
to the synchronization buffer in accordance with a 
comparison of a first signal derived from the decod- 
er system clock and a second signal derived from 
a timestamp from the selected data packets. 

[0011] The technique summarized below is a "soft- 
ware PLL-like" method to address the jitter and time syn- 



chronization for a client decoding system. It employs the 
RTP (Real-Time Transport Protocol) as the transport 
service and receiver buffering to achieve real-time A/V 
playback. 

5 [0012] The dejittering process can be achieved by a 
dejittering buffer using the embedded timestamp values 
in the transport packets and client RTP clock (which 
runs at the same frequency as the A/V decoder's clock). 
The delay variations of data arriving are removed after 
10 the client buffering process, the data packet is shifted to 
a synchronizing buffer at the scheduled time of server 
encoder, then feed to the A/V decoder according to the 
time reference of A/V encoder. The clock synchroniza- 
tion (recovery) can be achieved by a synchronizing buff- 
's er based on a reference fill position and the movement 
of the fill position in the buffer (packet index oriented). 
By monitoring the fullness of the buffer over a given pe- 
riod, the drift rate of clock unsynchronization between 
client and server can be derived. 

20 

Brief Description of the Drawings 

[0013] The invention is described in greater detail 
hereinafter, by way of example only, with reference to 
25 embodiments thereof which are described with the aid 
of the accompanying drawings, wherein: 

Figure 1 schematically illustrates a networked sys- 
tem for real-time audio/visual services comprising 

30 a plurality of client host and a server; 

Figure 2 schematically illustrates a client host com- 
prising a dejittering buffer and a software PLL-like 
architecture, wherein dejittering and clock recover- 
ing is achieved in accordance with an embodiment 

35 of the present invention; and 

Figure 3 diagrammatically illustrates the mecha- 
nism of timing synchronization via monitoring the 
position movement of the dejittering buffer. 

40 Detailed Description of the Preferred Embodiments 

[0014] In this specification, various aspects of the Re- 
al-Time Transport Protocol (RTP) and Resource Reser- 
vation Protocol (RSVP) are referred to. and a more de- 
45 tailed description of the mechanisms, protocols and sys- 
tems involved in implementing RTP and RSVP can be 
found in the following documents, the disclosures of 
which are incorporated herein by reference: 

so "RTP: A Transport Protocol for Real-Time Applica- 
tions", H. Schulzrinne, S. Casner, R. Frederick, V. 
Jacobson; RFC 1889, January 1996. 
"RTP Profile for Audio and Video Conferences with 
Minimal Control", H. Schulzrinne; RFC 1890, Janu- 

55 any 1996. 

"RTP Payload Format for MPEG1/MPEG2 Video", 
D. Hoffman, G. Fernando, V. Goyal, M.R. Civanlar; 
draff-ietf-avt-mpeg-new-01 , Internet draft, June 



3 



EP 0 987 894 B1 



6 



1997. 

"RTP Payload Format for Bundled MPEG", M.R. 
Civanlar, G.L Cash, B.G Haskell; draft-civanlar-bm- 
peg-01, Internet draft, February 1997. 
"Resource Reservation Protocol (RSVP) Version 1 
Function Specification", R. Braden, L. Zhang. S. 
Berson, S. Herzog, S Jamin, draft-ietf-rsvp-spec- 
16, Internet draft, June 1997. 

[0015] A system model for real-time services over a 
jitter introducing network is illustrated in block diagram 
form in Figure 1 . In the Figure, an A/V client server ar- 
rangement is shown, wherein a client 30 is connected 
to a sever 10 via a network 20. The server 1 0 includes 
a source of audio/video streams 11 , a RTP encoder 12, 
a server encoding system clock 13, transport and net- 
work layers 1 4 and a network interface 1 5. The client 30 
includes a network interface 31 , transport and network 
layers 32, a dejittering buffer 33, a RTP decoder 34, a 
client decoding system clock 35, a time synchronizing 
buffer 36 and an audio/video decoder 37. The network 
20 is a jitter introducing network, such as IP-based net- 
work. The overall operation of the present invention in 
this environment is described hereinbelow. 
[0016] At the server 1 0, AV stream source 1 1 is input 
to the RTP encoder 12. The output of RTP encoder 12 
are RTP packets where their payload field contain data 
from source 11 . These packets are timestamped by the 
server system encoding clock 13, and then sent out to 
the client through the network 20 at constant bit rate. At 
the client 30, the RTP packets (containing AV stream 
data in payload field) received from the network are put 
into the dejittering buffer 33 in sequence. The RTP pack- 
ets in dejittering buffer 33 are decoded by the RTP de- 
coder 34 and client decoding system clock 35, and then 
shifted into the time synchronizing buffer 36. In other 
words, the synchronizing buffer 36 will contain ail the 
original A/V stream data from A/V source 11 . These A/ 
V stream data will then be fed into A/V decoder accord- 
ing to their appropriate time scheduling. 
[0017] The desirable size of the dejittering buffer de- 
pends only on the maximum network jitter J max (peak- 
to-peak) and the maximum bit rate of A/V streams R max . 
Assume the difference of clock counting between the 
server and client over the period of updating (T, which 
for example can be default to 1 minute) is f. The size of 
the dejittering buffer can be determined by: 



[0019] Therefore, a size of 128 kBytes buffer should 
be adequate for most situations if a certain level of QoS 
is also guaranteed. 

[0020] Figure 2 is a block diagram of the dejittering 
5 and clock recovering operation in accordance with an 
embodiment of the present invention. In this diagram, 
and the following description: 

TC is the time counter of the client's RTP clock 
w tc n is the time counter value for the n^ packet 
ts n is the time timestamp value of the n* packet in 

the dejitter buffer 
tc is the adjustment value for TC, when necessary. 

15 [0021] As detailed in the block diagram of Figure 2, 
the dejittering process is done based on the encoded 
RTP timestamp value and client's RTP clock. At the first 
step, the client buffer provides the function of buffering 
by way of dejitter buffer 33, which removes the jitter in 
20 terms of client reception. The dejitter buffer 33 is cou- 
pled to pass data to the synchronizing buffer 36 by way 
of a shift gate 41 . The shift gate 41 is controlled by the 
output of a comparator 42 which has inputs tc n from the 
client's RTP clock time counter and ts n retrieved from 
25 the dejitter buffer. The data is shifted to the synchroniz- 
ing buffer 36 wheneverthe timestamp value (ts n ) encod- 
ed in the packet is equal to the client's time counter value 
(tc n ). The packets in the synchronizing buffer are A/V 
data packets. Such data packets are fed to the A/V de- 
30 coder (e.g. MPEG decoder) based on their own embed- 
ded time schedule. It should be noted here that in the 
case of a system decoder the decoder internal system 
buffer can be used as the synchronizing buffer if it is 
accessible from the client. 
35 [0022] The clock synchronization between client and 
server is achieved via monitoring the packet position in 
the synchronizing buffer. The size of the synchronizing 
buffer can be quite small since it only needs to handle 
the clock drift. The operation is illustrated in Figure 3 
40 which is a diagram of buffer monitoring for time synchro- 
nization. Here the operation of the clock recovery proc- 
ess is based on the buffer position change compared 
with the reference position (defined as the buffer half- 
size position) for a given period T (for example, every 
45 minute). If the buffer position is moving in the direction 
of emptiness, the counter TC should be upwardly ad- 
justed by adding an offset. If the buffer position is moving 
in the other direction (fullness), the TC value should be 
downwardly adjusted. The drift rate r of clock unsyn- 
so chronization between server and client can be deter- 
mined by: 



[001 8] For example, if J max = 1 00ms, R max = 8Mbps 
and f = 10 ms, then the required minimum buffer size is, 



r=(P 2 "Pi) / 7 



S . = (100 + 10) x 8% 10 6 = 880,000 



■ bit 



: 880,000/8 (Bytes) = 7 10,000 - byte < 128 kBytes 



[0023] It should be noted that the buffer position men- 
tioned above is in terms of packet index offset rather 
than the byte number offset. 
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[0024] It is also possible to implement the present 
technique with the use of one buffer only (no additional 
synchronizing buffer available). In such case, data pack- 
ets are fed into the A/V decoder directly from the dejit- 
tering buffer at the scheduled time. The above clock drift 
rate /will include the component of network jitter J and 
should be eliminated before the TC is adjusted. The in- 
terarrival jitter Jean be derived from the two sequenced 
RTP packets. The jitter J is defined to be the mean de- 
viation of the difference (D) in packet spacing at the re- 
ceiver compared to the sender for a pair of packets. For 
example, if is the RTP timestamp from packet a, and 
Tft, is the time of arrival in RTP timestamp units for pack- 
et b. then for these two packets, we have, 

j=D(a,b) 

[0025] The j is calculated continuously as each data 
packet is received from server, then according to the for- 
mula, we have, 

J= J + (\j\ - J)/16 

[0026] This algorithm provides an optimal first-order 
estimator and the gain parameter 1/16 gives a good 
noise reduction ratio while maintaining a reasonable 
rate of convergence (see RTP specification and related 
references). 

[0027] Unlike the traditional method (using a PLL cir- 
cuitry) and other available technique (such as that dis- 
closed in European patent No. EP779725, entitled 
"Method and Apparatus for Delivering Simultaneous 
Constant Bit Rate Compressed Video Streams At Arbi- 
trary Bit Rates with Constrained Drift and Jitter", which 
uses two levels of synchronization named coarse-grain 
and fine-grain for video streams to control drift and jit- 
ter), the present method is a more independent and less 
constrained client-based approach. It provides the net- 
work adaptability via a simple software solution (can be 
implemented in hardware as well) for an end system and 
can be applied in a wide range of network applications. 
The effect of the present technique includes: 

increasing the adaptability of decoding systems (in 
terms of dejittering and clock synchronization); 
simplifying the decoder implementation (no PLL cir- 
cuitry required); 

handling more types of audiovisual streams (not 
only MPEG2 system streams); 
application to different types of environments (uni- 
cast as well as multicast); 

beneficial to the effort of expanding rea-time A/V 



services over IP-based network such as Internet. 



Claims 

5 

1 . A method for checking variation compensation in an 
audio/visual system in which encoded A/V data in 
a plurality of data packets are delivered to at least 
one client over a network from a server at a sub- 

10 stantially constant bit rate, said plurality of data 
packets including data packets containing times- 
tamp data, the method comprising the steps of: 

receiving and buffering the data packets in a 
15 first buffer at a client; 

passing selected data packets from the first 
buffer to a second buffer at scheduled times 
based on a comparison between a local clock 
of the client and timestamp data corresponding 
20 to the selected data packets; and 

passing the data from the second buffer to a 
data decoder of the client. 

2. A method as claimed in claim 1 , including monitor- 
25 ing the fullness of the second buffer to derive a drift 

rate, and adjusting the client local clock based on 
the derived drift rate. 

3. A method as claimed in claim 1 or 2, wherein the 
30 scheduled time is determined by a substantially ze- 
ro difference between the value of a said timestamp 
data corresponding to the selected data packets 
and a clock counter from the client local clock. 

35 4. A method as claimed in claim 2, wherein the drift 
rate is derived according to: 

r=(p2-p1)/T 

40 

where: 

ris the derived drift rate, and 
p2 and p1 are two corresponding buffer posi- 
45 tions for a given period of time 7. 

5. An audio/visual system coupled to receive data 
packets over a network for A/V decoding by an A/V 
decoder, the system including a clock variation 
so compensation system comprising: 

a dejitter buffer for receiving and storing pack- 
ets of data from the network; 
a synchronization buffer for feeding data for de- 
55 coding to the A/V decoder; 

a decoder system clock; and 
a buffer data flow controller for controlling the 
passing of selected data packets from the de- 
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jitter buffer to the synchronization buffer in ac- 
cordance with a comparison of a first signal de- 
rived from the decoder system clock and a sec- 
ond signal derived from a timestamp from the 
selected data packets. 

6. A system as claimed in claim 5, further including a 
clock adjustment controller coupled to monitor a 
measure of the fullness of one of the synchroniza- 
tion and dejitter buffers, and coupled to the decoder 
system clock to allow adjustment thereof based on 
the buffer fullness measurement. 



Pate ntansp ruche 

1. Verfahren zur Oberprufung der Variationskompen- 
sation in einem audiovisuellen System, wobei ko- 
dierte A/V-Daten in mehreren Datenpaketen an zu- 
mindest einen Client uber ein Netz von einem Ser- 
ver mit einer im wesentlichen konstanten Bitrate ge- 
schickt werden, wobei mehrere Datenpakete Da- 
tenpakete aufweisen, die zeitprotokollierte Daten 
enthalten, wobei das Verfahren die folgenden 
Schritte aufweist: 

Empfangen und Puffem der Datenpakete in ei- 
nem ersten Puffer bei einem Client; 
Weitergeben ausgewahlter Datenpakete von 
dem ersten Puffer an einen zweiten Puffer zu 
planmaBigen Zeiten, die auf einen Vergleich 
zwischen einem lokalen Zeitgeber des Clients 
und zertprotokollierten Daten basieren, die den 
ausgewahlten Datenpaketen entsprechen; und 
Weitergeben der Daten von dem zweiten Puffer 
zu einem Daten dekodierer des Clients. 

2. Verfahren nach Anspruch 1 , bei dem die Belegung 
des zweiten Puffers uberwacht wird, um eine Drift- 
rate abzuleiten, und bei dem der lokale Taktgeber 
des Clients auf der abgeleiteten Driftrate basierend 
angepaBt wird. 

3. Verfahren nach Anspruch 1 Oder 2, wobei die plan- 
maBige Zeit durch im wesentlichen einen Nullunter- 
schied zwischen dem Wert der zeitprotokollierten 
Daten, die den ausgewahlten Datenpaketen ent- 
sprechen, und einem Taktzahler von dem lokalen 
Taktgeber des Clients bestimmt wird. 

4. Verfahren nach Anspruch 2, wobei die Driftrate ab- 
geteitet wird gemaB: 

r=(p2-p1)/T, 

Vv'CbCi 



r die abgeleitete Driftrate und 

p2 und p1 die entsprechenden Pufferpositio- 

nen fur ein vorgegebenes Zeitintervall T sind. 

s 5. Ein audiovisuelies System, das gekoppelt ist, um 
Datenpakete uber ein Netz zum A/V-Dekodieren 
durch einen A/V-Dekodierer zu empfangen, wobei 
das System ein System fur die Taktvariationskom- 
pensation umfaBt, das aufweist: 

10 

einen Dejitter- Puffer zum Empfangen und zum 
Speichem von Datenpaketen von dem Netz- 
werk; 

einen Synch ronisationspuffer zum Zufuhren 
15 von Daten zum Dekodieren zu dem A/V-Deko- 

dierer; 

einen Zeitgeber des Dekodierersystems; und 
eine Steuerung fur den PufferdatenfluB, um 
das Weitergeben ausgewahlter Datenpakete 

20 von dem Dejitter- Puffer zu dem Synch ronisati- 

onspuffer gemaB einem Vergleich zwischen ei- 
nem ersten Signal, das von dem Taktgeber des 
Dekodierersystems abgeleitet ist, und einem 
zweiten Signal, das von einem Zeitprotokoll der 

25 ausgewahlten Datenpakete abgeleitet ist, zu 

steuern. 

6. System nach Anspruch 5, das auBerdem eine 
Steuerung fur die Taktanpassung aufweist, die ge- 

30 koppelt ist, um ein MaB der Belegung von entweder 
dem Synchronisationspuffer Oder dem Dejitter-Puf- 
fer zu uberwachen, und mit dem Taktgeber des De- 
kodierersystems gekoppelt ist, um dessen Anpas- 
sung auf Grundlage der Messung der Pufferbele- 

35 gung zu ermoglichen. 



Revendlcatlons 

40 1 . Precede pour verifier la compensation de la fluctua- 
tion d'un systeme audio visuel dans lequel des don- 
nees A / V codees dans une pluralite de paquets de 
donnees sont fournies a au moins un client sur un 
reseau a partir d'un serveur qui possede un d6bit 

45 binaire sensiblement constant, ladite pluralite de 
paquets de donnees comprenant des paquets de 
donnees qui contiennent des donnees horodatees, 
le procede comprenant les etapes consistant a : 

so recevoir et tamponner les paquets de donnees 

dans un premier tampon situe au niveau d'un 
client ; 

transferer les paquets de donnees selection- 
nes a partir du premier tampon vers un second 
55 tampon a des instants prevus sur la base d'une 

comparaison entre une horloge locale du client 
et les donnees horodatees qui correspondent 
aux paquets de donnees seiectionnes ; et a 
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transferer les donnees a partir du second tam- 
pon vers un decodeur de donnees du client. 

2. Precede selon la revendication 1, comprenant la 
surveillance de I'etat plein du second tampon pour 5 
deliver un taux de derive, et ajuster I'horioge locale 

du client sur la base du taux de derive derive. 

3. Precede selon Tune quelconque des revendications 

1 ou 2, dans lequel Tinstant prevu est determine par io 
une difference sensiblement nulle entre la valeur 
desdites donnees horodatees qui correspondent 
aux paquets de donnees selectionnes et un comp- 
teur d'horioge provenant de I'horioge locale du 
client. 15 

4. Precede selon la revendication 2, dans lequel le 
taux de derive est derive selon : 

20 

r=(p2-p1)/T 

ou: 

rest le taux de derive derive, et 25 
p2et p1 sont deux positions correspond antes 
du tampon pendant une periode donnee T. 

5. Systeme audio visuel couple pour recevoir des pa- 
quets de donnees sur un reseau pour etre deco- 30 
dees par un decodeur A/V, le systeme comprenant 

un systeme de compensation de la fluctuation de 
I'horioge qui comprend : 

un tampon de suppression de la gigue pour re- 35 
cevoir et stocker des paquets de donnees qui 
proviennent du reseau. ; 
un tampon de synchronisation pourfournir des 
donnees a decoder au decodeur A / V ; 
une horloge systeme de decodeur ; et 4 <> 
un contrdleur du flux de donnees du tampon 
pour commander le transfert des paquets de 
donnees selectionnes, a partir du tampon de 
suppression de la gigue vers le tampon de syn- 
chronisation, selon une comparaison entre un ^5 
premier signal derive de I'horioge systeme du 
decodeur et un second signal derive d'un horo- 
datage provenant des paquets de donnees se- 
lectionnes. 

50 

6. Systeme selon la revendication 5, comprenant de 
plus un controleur de reglage d'horioge couple pour 
surveiller une mesure de I'etat plein de Tun des tam- 
pons de synchronisation et de suppression de la gi- 
gue, et couple a I'horioge systeme du decodeur ss 
pour permettre un reglage de celle-ci sur la base de 

la mesure de I'etat plein du tampon. 
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